Lab 4 - Firewalls and filters

This unit provides basic coverage of the tools and techniques for firewall and filtering traffic on a Linux system.

Notice: Please take a full back up of your lab VM before attempting this lab. You may need to restore from backup to return your lab VM to its original working state.

iptables Basics

This activity will familiarize you with the basics of creating rules for iptables chains and verifying whether your rules do what you wanted them to do.

  1. connect to your server’s ssh service with a terminal window or with putty

  2. Log in to the student account

  3. Since we are using a prebuilt VM that has ufw configured, save the existing ufw configuration. ONLY DO THIS ONCE, EVEN IF YOU RESTART THE LAB

    sudo ufw show added >~/`date +%Y%m%d%H%M-ufw-rules-saved.$$` 
    sudo ufw show added >~/`date +%Y%m%d%H%M-ufw-rules-saved.$$`

  4. Clear out the leftovers from iptables

    sudo ufw reset
sudo iptables -F
sudo iptables -X 
    sudo ufw reset
sudo iptables -F
sudo iptables -X

  5. Verify you can connect to your VM using a web browser

    • use the IP address of your host-only network interface (ip a s <host-only_interface>). We are only using ens33 as an example, you should change this to the name of your interface attached to your host-only network.
    • access the cockpit service at http://W.X.Y.Z:9090 (W.X.Y.Z should be your VM’s host-only network IP address)
    • log in to the cockpit service with the student login and password that used for ssh

  6. Create a set of iptables rules to

    • allow any traffic on the loopback interface

    • allow ssh inbound traffic on your ens33 interface

    • log and count any input tcp traffic that is not destined for your ssh service

    • set the INPUT and OUTPUT policy to DROP

      iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i ens33 -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -i ens33 -p tcp \! --dport ssh -c 0 0 -j LOG --log-prefix "INPUT DENIED: "
iptables -P INPUT DROP
iptables -P OUTPUT DROP 
      iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i ens33 -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -i ens33 -p tcp \! --dport ssh -c 0 0 -j LOG --log-prefix "INPUT DENIED: "
iptables -P INPUT DROP
iptables -P OUTPUT DROP

  7. Is your cockpit web page still updating?

  8. Does your ssh session still work?

  9. See what is getting logged for your iptables rules

    sudo grep DENIED /var/log/kern.log 
    sudo grep DENIED /var/log/kern.log

  10. View your iptables rules using the -L and -S options

    sudo iptables -L
sudo iptables -S 
    sudo iptables -L
sudo iptables -S

  11. Which one is more useful to see your rules?

  12. Reboot your VM

  13. View your iptables rules again. Did the reboot change anything?

Iptables Persistence

  1. Reinstall the iptables rules from the first part of the lab and verify they are present

    iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i ens33 -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -i ens33 -p tcp \! --dport ssh -c 0 0 -j LOG --log-prefix "INPUT DENIED: "
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -L 
    iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i ens33 -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -i ens33 -p tcp \! --dport ssh -c 0 0 -j LOG --log-prefix "INPUT DENIED: "
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -L

  2. Install the iptables-persistent package, without agreeing to save the rules during installation of the package

    sudo apt install iptables-persistent 
    sudo apt install iptables-persistent

  3. Save your IPV4 rules with the iptables-save command

    sudo iptables-save |tee /etc/iptables/rules.v4 
    sudo iptables-save |tee /etc/iptables/rules.v4

  4. Examine the contents of /etc/iptables/rules.v4 and compare it to the output of iptables-save

  5. Reboot and verify your rules are automatically reinstalled

    reboot 
    reboot

  6. Remove the iptables-persistent package

    sudo apt remove iptables-persistent 
    sudo apt remove iptables-persistent

  7. Reboot and check if your rules are still getting installed at boot

    reboot 
    reboot

Kernel Tuning with sysctl

  1. Run sysctl -a to get an idea of the kernel parameters currently set up on your system
  2. What are the security implications of being able to retrieve this type of information as an ordinary user?
  3. https://www.kernel.org/doc/Documentation/sysctl/vm.txt has excellent sysctl documentation for kernel version 2.6 (still in use in production systems and embedded systems)
    • Find the swappiness parameter in that document to see what it can do for you
    • Check out the Wikipedia article for more info

Performance tuning also affects resiliency, example of references on tuning for performance include:

Iptstate

  1. Install iptstate package

    sudo apt install iptstate 
    sudo apt install iptstate

  2. Clear your iptables rules and add back the rules we have been using, but with connection tracking turned on for new connections to the ssh service

    sudo ufw reset
sudo iptables -F
sudo iptables -X
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A OUTPUT -o lo -j ACCEPT
sudo iptables -A INPUT -i ens33 -p tcp --dport ssh -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A INPUT -i ens33 -p tcp \! --dport ssh -c 0 0 -j LOG --log-prefix "INPUT DENIED: "
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT DROP 
    sudo ufw reset
sudo iptables -F
sudo iptables -X
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A OUTPUT -o lo -j ACCEPT
sudo iptables -A INPUT -i ens33 -p tcp --dport ssh -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A INPUT -i ens33 -p tcp \! --dport ssh -c 0 0 -j LOG --log-prefix "INPUT DENIED: "
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT DROP

  3. Run iptstate and observe the various connections being tracked by iptables

    sudo iptstate -f 
    sudo iptstate -f

  4. Use iptables -L -v to see the packet and byte counts being seen by the various rules you have in place

    sudo iptables -L -v 
    sudo iptables -L -v

UFW

UFW is already installed on the lab VM.

  1. Clear out the iptables rules we currently have, as well as any leftover ufw rules

    sudo ufw reset
sudo iptables -F
sudo iptables -X 
    sudo ufw reset
sudo iptables -F
sudo iptables -X

  2. Use ufw to allow ssh traffic

    sudo ufw allow ssh 
    sudo ufw allow ssh

  3. Check your status with ufw, enable it, and recheck your status

    sudo ufw status
sudo ufw enable
sudo ufw status 
    sudo ufw status
sudo ufw enable
sudo ufw status

  4. Run iptables -L -v with the ufw firewall tool in the enabled state

    sudo iptables -L -v 
    sudo iptables -L -v

  5. Disable the ufw firewall tool and see what is left behind in your live iptables

    sudo ufw disable
sudo ufw status
sudo iptables -L 
    sudo ufw disable
sudo ufw status
sudo iptables -L

  6. Clear out your tables for the next exercise

    sudo ufw reset
sudo iptables -F
sudo iptables -X 
    sudo ufw reset
sudo iptables -F
sudo iptables -X

Ipkungfu

  1. Install the ipkungfu package and check its state after installation

    sudo apt install ipkungfu
sudo ipkungfu -c 
    sudo apt install ipkungfu
sudo ipkungfu -c

  2. Note the configuration files in /etc/ipkungfu

  3. Modify ipkungfu.conf to set GATEWAY=0, DISALLOW_PRIVATE=0

    sudo vi /etc/ipkungfu/ipkungfu.conf 
    sudo vi /etc/ipkungfu/ipkungfu.conf

  4. Modify services.conf to ACCEPT ftp and ssh traffic

    sudo vi /etc/ipkungfu/services.conf 
    sudo vi /etc/ipkungfu/services.conf

  5. Run ipkungfu –show-vars to see your current configuration with ipkungfu’s guesses and correct any settings you can see are not right for your VM

    sudo ipkungfu --show-vars 
    sudo ipkungfu --show-vars

  6. Run ipkungfu -t to test and install your new configuration

    sudo ipkungfu -t 
    sudo ipkungfu -t

  7. Use iptables -L to see the new iptables configuration

    sudo iptables -L 
    sudo iptables -L

  8. Check /etc/default/ipkungfu to see if it is enabled on system startup (IPKFSTART setting) and make sure it is disabled before doing fail2ban

    sudo cat /etc/default/ipkungfu 
    sudo cat /etc/default/ipkungfu

Fail2ban

For this activity, you will want to have 2 separate terminals or putty windows running at the same time. Do the steps up to monitoring the log file in the first window, and then switch to the other window to cause the failed logins. Once you do that, the IP address that the failures are coming from will be banned, so be sure your second session isn’t coming from the same IP address as your first session.

  1. Clear out your tables before starting the exercise

    sudo ufw reset
sudo iptables -F
sudo iptables -X 
    sudo ufw reset
sudo iptables -F
sudo iptables -X

  2. Install fail2ban

    sudo apt install fail2ban 
    sudo apt install fail2ban

  3. Use fail2ban-client to see the default configuration that is running

    sudo fail2ban-client status 
    sudo fail2ban-client status

  4. Check the status of default sshd jail that is installed

    sudo fail2ban-client status sshd 
    sudo fail2ban-client status sshd

  5. Start monitoring the fail2ban.log using tail -f to see what the service does for the next steps

    sudo tail -f /var/log/fail2ban.log 
    sudo tail -f /var/log/fail2ban.log

  6. Use a second terminal/putty window to login to your VM from a different machine than your other ssh session, but give the wrong password 6 times in a row while watching the fail2ban log in your other ssh session

  7. Once the service bans your ip according to the watched logfile, cancel the logfile monitoring using ^C (ctrl-c) and examine the ban with the following commands in the terminal window that is still working

    fail2ban-client status sshd
fail2ban-client get sshd bantime 
    fail2ban-client status sshd
fail2ban-client get sshd bantime

  8. Clear the ban manually

    fail2ban-client set sshd unbanip w.x.y.z
fail2ban-client status sshd 
    fail2ban-client set sshd unbanip w.x.y.z
fail2ban-client status sshd

  9. Verify your second terminal/putty window can connect using ssh again